Adaptive Connection for Data Transmission 

This application claims the benefit of and incorporates by reference the entirety of 
United States Provisional Patent Applications 60/468,616 filed May 5, 2003 entitled 
"ADAPTIVE CONNECTION FOR DATA TRANSMISSION" and 60/453,935 filed 
March 12, 2003 entitled "INTERNET CONNECTION SYSTEM." 
Technical Field of Invention 

The present invention relates to data transmission, in particular, to a novel 
connection solution adaptive to both a sending application and the receiving application 
without a need for changing the applications, even when the applications are not of the 
same protocol, of the same platform, or compatible to each other. Furthermore, the novel 
adaptive connection leverages internet protocols while still being able to perform secure 
and reliable data transmission. 

Background of the Invention: 

Information transmission between an enterprise and its suppliers, customers 
and/or partners is a fundamental business process, which requires a secure and reliable 
connectivity. Information transmission over a data network, however, is still limited to 
only a small fi-action of endpoints because of its high cost to implement even for a large 
enterprise. Enterprises need connectivity strong and robust enough to exchange mission 
critical business data, which requires enterprises to manage a complex, costly and time 
consuming deployment process. Often, solutions must be custom-built and are limited to 
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specific internal applications. Protocol and platform incompatibilities between enterprises 
prevent applications from being connected, and for some enterprise solutions, every 
endpoint must utilize the same messaging infi-astructure. Obviously, this is not applicable 
to a now widely diverse, heterogeneous environment in which the enterprises struggle. 

The Intemet offers a ubiquitous backbone with open, flexible protocols, which 
may substantially slash the cost of connectivity and extend an organization's connectivity 
reach. It, however, does not inherently provide the security and reliability that 
corporations need to exchange important business information, nor does it provide the 
asynchronous processing paradigms needed for effective application-to-application 
integration. 

Thus, there exists a need for a technique to leverage intemet protocols - both 
inside the enterprise and across firewalls - to their suppliers, partners, and customers. 
Moreover, for a rehable transmission of important enterprise data, the users involved are 
always interested in a capability to track the transmission status. 

Summary of the hivention 

To achieve the above objectives, a new connection system is provided for 
message transmission from a sending application at one computer to a receiving 
application at a second computer, hi particular, the connection system comprises a first 
gateway to interface the sending application with a first protocol, a second gateway to 
interface the receiving application with a second protocol, and a connection server 
bridging between the first and second gateways over a network for receiving the message 
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from the first gateway and forwarding the same to said second gateway. Thus, the 
sending apphcation and the receiving apphcation do not need to match in protocol to 
communicate. In a preferred embodiment, the first and/or second protocol uses one of 
several standard Internet protocols. 

The connection system may generate tracking information for each message 
transmission, which includes at least the tracking number and the transmission status. The 
tracking number is provided to the first and/or second computers, and the tracking record 
may be kept in the connection server or a separate tracking information server, which is 
preferably accessible by the users over the Intemet. 

Each of the gateways may keep a plurality of interfaces, each suitable for a 
specific protocols. The gateways preferably include ports for various protocols such as 
HTTP, SMTP, FTP, or others. These ports are termed listeners, each gateway having 
plural listeners so that it may interface with each protocol. Each gateway communicates 
with the associated application using the protocol implemented by that application. Thus, 
the first gateway may communicate over a specified port with an application using 
HTTP, and the second gateway may communicate with its associated application using a 
different port number and a different protocol. Each gateway has plural ports with which 
to listen, and preferably each port will convey data using a predetermined protocol 
associated with that port. 

Morphing modules may be provided in the gateways to examine and modify the 
message if necessarily. In particular, a morphing module is provided at the second 
gateway to change the data to a format suitable to the receiving application. The 
morphing module may perform fiirther fimctionality. For example, morphing may 
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validate certain messages, and declare others to be unauthorized by conveyance to the 
receiving application. The morphing module may require authorization to convey 
messages, may discard certain messages in part or in their entirety, or may perform any 
other filtering functions with respect to the communications being conveyed. The 
morphing module operates as a configurable filter, which may be configured based upon 
user preferences, the expected traffic types and flow, or other suitable parameters. 

The message or data transmitted is encrypted at the first gateway, enclosed in an 
"envelope" for transmission, and is decrypted at the second gateway. 

Brief Explanation of the Drawings: 

The above and other features and advantages will be clearer after reading the 
following detailed description of the preferred embodiment of the invention, with 
reference to the accompanying drawings, in which: 

• Fig. 1 illustrates a basic adaptive connection topology of the present invention; 

• Fig. 2 illustrates in more detail the elements in the inventive adaptive connection 
system; 

• Fig. 3 is a flow chart showing the message transmission stages in the system of 
Figure 2; and 

• Fig. 4 illustrates a tracking server incorporated in the connection system. 

Detailed Description of the Preferred Embodiments: 

Figure 1 shows a basic topology of the data/message transmission from a source 1 
to a destination 2, in which the adaptive connection system 10 of the present invention is 
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incorporated. The inventive adaptive connection system 10 basically comprises a 
connection server 1 1, a source gateway 12 and a destination gateway 13. As shown in 
Figure 1, the source gateway 12 is capable of interfacing any one of the appUcations 3 
with corresponding one of several internet protocols, e.g., SMTP, FTP or HTTP. For 
example, if data is sent from an EDI application using FTP protocol, the source gateway 
12, will receive such data on the port associated with FTP. As shown in Figure 2 with 
more detail, this is done by employing plural listeners 121, provided in the source 
gateway 12. Thus, the source gateway 12 is capable of communicating with any of the 
applications 3, no matter what internet protocol is used by the sending application, 
because the gateway 12 includes various Usteners that each operate on different ports. 

A major consequence of the adaptive protocol handler, or the listener 121, is that 
applications 3 do not need to contain logic that invokes the API of message queuing 
systems with which they may commimicate. This greatly expands the number of 
applications that can participate in a business connectivity solution. Another benefit of 
the adaptive protocol handler 121 is that it makes business connectivity non-intrusive 
since applications 3 do not need to be changed, regardless of the conununications 
protocol being utilized, and regardless of the application running a computer with which 
the application is communicating. 

With the appropriate listener, the source gateway 12 receives the data from 
sending application 3, which includes the address information of the desired destination 
2. The protocol to be utilized by the desired destination is determined by the connection 
server. This determination allows the destination gateway 13 to determine which 
protocol and which port to use in communicating with the receiving application . The 
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data is then sent to the connection server 1 1 through a data network 14. The connection 
server 1 1 also extracts the destination address information to route the data to the 
destination gateway 13, through a data network 15. 

Upon receipt of the data from the connection server 1 1, the destination gateway 
13, is caused to utilize the protocol that matches the protocol used by the destination 
application 4, as indicated by the connection server 1 1 . This is done by a connector 131 
provided in the destination gateway 13. Thus, the data is successfully sent from the 
destination gateway 13 to a receiving application 4 at the desired destination 2, which 
may be using a different protocol from the one used by the sending application, or even 
running on a different platform. For instance, data can be sent via HTTP and placed on an 
MQ series queue at the receiving end. Apphcations using .NET'S underlying queuing 
technology, MSMQ, can exchange data with applications using a different (or no) 
queuing system. No commitment to a major new infrastructure is required. 

With the connection server 1 1 standing between the source 1 and the destination 
2, asynchronous data transmission can be realized even when both sending and receiving 
apphcations 3 and 4 are synchronous ones. 

A fimdamental business connectivity requirement is the ability to transform, or 
morph, business data from the sender's application format into the format of the 
receiver's application. Recipient companies may use differing applications, so the 
technology must allow data to morph differently depending on the specific destination 
application's needs. To this end, one or more morphing modules 122 and 132 are 
provided in the source gateway 12 and the destination gateway 13 to examine and modify 
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the data. In particular, the morphine 132 in the destination gateway 13 may aher the 
received data to a format that is suitable to the receiving application 4. 

Figure 3 shows a flow chart depicting the data transmission sent from the source 
1, through the connection system 10 reaching the desired destination 1 1, as illustrated in 
Figures 1 and 2. The data is generated by an application 3 (e.g., HTTP application, 
message queue, etc.) at the source 1, at step 100. With the proper protocol the data is 
received by the source gateway 12, at step 101. At the source gateway 12, the data is 
undergoing morphing (possibly by multiple morphing modules) at step 102, then is 
queued onto a message queue 123 to go to the connection server 1 1, at step 103. The data 
is retrieved by the connection server 1 1, at step 104, and goes through the routing process 
by a routing module, at step 105, and then is queued onto a message queue 1 12 to go to 
the destination gateway 13, at step 106. The data is retrieved by the destination gateway 
13 at step 107. Again, the data undergoes morphing at step 108, possibly tailored to the 
format required by the receiving appUcation 4. Finally the data is sent to its final 
destination at step 109, and a response is generated to indicate the successful 
transmission. 

For the security of data transmission, the data is encrypted at the source gateway 
12, and is decrypted at the destination gateway 13. Furthermore, it is important to provide 
traceable and auditable information to the users regarding their data transmissions. 

As shown in Figure 4, a tracking server 20 is provided to keep and maintain a 
tracking record for each data transmission. Typically, a tracking number is generated for 
a specific data transmission at the source gateway 12 upon receipt of the data from the 
sending application. The status of the data transmission at some steps from 101 to 109 are 
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reported from the related servers and/or gateways directly to the tracking server 20, or 
forwarded by the connection server 1 1 to the tracking server 20. The tracking server 20 
can be the same one as the connection server 11, or a separate one remotely located from 
the connection server 1 1 . 

Preferably, the tracking server 20 is accessible by the user over the Internet, e.g., 
through a browser in a display 21, with the tracking number that he has received from the 
source gateway or connection server 1 1 or the tracking server 20. This will permit a user 
to ascertain the status of the data transmission. Additionally, tracking numbers may be 
assigned by any other source connected to the network. Messages may also be tracked 
using any other parameter of the message, rather than a tracking nimiber. 

Preferably, auditing information is provided by the source gateway 1, or by the 
destination gateway 2, or by both. Auditing information can be added to the message 
being conveyed, or can be provided to the connection server 1 1 or to the tracking server 
20 so as to be added to the tracking information. 

The connection server 1 1 can be remotely located from both gateways 12 and 13, 
and the data link 14 and 15 can be the Intemet, a LAN, or a WAN. Firewalls may be put 
between the gateways 12, 13 and the connection server 11. It is also possible to locate 
the connection server 1 1 at the same node with one of the gateways 12, 13. 

We will now describe in fiirther detail the convenience and acknowledgement of a 
message from one of applications 3 to applications 4. In operation, a message that is to 
be acknowledged would traverse the system of Figure 3 from left to right. The message 
leaves one of applications 3 and arrives at gateway 12 via the appropriate one of the 
plural Usteners installed at gateway 12. The gateway 12 would include listeners for most 
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or all standardized Internet protocols (HTTP, FTP,SMTP) as well as listeners for 
operating from known queuing systems (e.g. MSMQ, Websphere, etc) and file systems. 

Messages may optionally then be processed by a filtering and morphing module. 
As described above, this step may result in some messages being altered, discarded, 
partially transmitted, etc. The parameters of the filtering and morphing are user 
configurable and highly flexible. 

After optional filtering and morphing, the message is placed into a queuing 
system that I responsible for reliable delivery of the message once and only once. In the 
event of network outages, the system will continue to retry transmission as necessary in 
order to achieve delivery of the message once and only once. 

At the connection server 11, the URI of the message is parsed and utihzed to 
forward the message to its destination. The destination information associated with a 
message comprises preferably both the type of destination (e.g. web server, FTP server, 
SMTP server, etc) as well as the location of that destination. The destination 
information may contain the location of a gateway connected to the destination in 
addition to, or instead of, the destination information itself 

After the destination information is added, the message is then queued again at the 
server 1 1, and forwarded in a reliable and secure manner to destination gateway 13. 
tracking information may be generated and/or maintained at any of the gateways 12 and 
13 or connection server 11. In addition, any of the aforementioned may communicate 
with one or more other computers to generate and store the tracking, audit, or other 
parameters related to the transmission of the message. 
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Upon arrival at destination gateway 13, the message may again be put through 
morphing and filtering modules, which can alter, reject, or allow the message. The 
implementation of morphing and filtering at gateway 13 need not operate based upon the 
same parameters as that in gateway 12. Thus, although gateway 12 may determine that a 
particular type of message is suitable to transmit to a particular application 4, and thus 
permit passage of that message, the destination gateway 13 may nonetheless reject that 
message. 

After arriving at the destination gateway 13, the message is passed to the 
appropriate port (i.e.; listener) to transmit the message to the destination application. 
That listener could be, for example, FTP, SMTP, or HTTP. Upon receipt, the response 
message may be conveyed in the opposite direction back to the application 3, or a 
response may also be sent to a third destination that stores such response. 

Though the preferred embodiments of the present invention have been described 
in detail as above, it shall be appreciated that numerous adaptations, variations and 
changes are possible to a skilled person in the art without departing fi-om the spirit of the 
invention. Therefore, the scope of the invention is intent to be solely defined in the 
accompanying claims. 
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